═══ 1. SockD description ═══ The multi-threaded socks server for OS/2 enables to build a firewall gateway on an OS/2 (Warp) system. The objective is just to interconnect small TCP/IP PC Lan with the public network (through a "Service Provider"). Like in all "standard" sockd server, the protection is build in a configuration file (sockd.cfg in the ETC directory). Access is controlled with two statements "deny" or "permit". Origin address and subnet mask and destination address and mask can be checked for a destination port number... For applications using socks version 4 protocol the support is only for TCP application due to the protocol stack. The current version has support for three LAN adapters (LAN0, LAN1 and LAN2), and two SLIP or PPP adapters (sl0, sl1, ppp0 and ppp1). One of the "serial" adapters can be configured in "auto-dial" to give access to the Internet through a "network" provider. The current version supports SOCKS Version 4 and 5. In SOCKS version 5, only NO AUTHENTICATION REQUIRED and USERNAME/PASSWORD authentication methods are supported. The GSSAPI support is NOT implemented. In V5 only support for IP V4 addresses is provided not V6. DNS names are evidendly supported. To be used, a correct support of the TCP/IP names must be implemented in the way the "client" stations can convert external names in IP addresses. This restriction can be modified with SOCKS Version 5 where DNS names have to be resolved only on the SOCKD station. To provide the correct "names" support in Socks V4, we use the DNS kit of TCP/IP V2.0 on the same workstation as "sockD". In this way this "nameD" server can provide caching mechanism to the external (and internal) name servers. We used also the DDNS kit of Warp Server in a similar configuration. In Socks V5, only a resolv file pointing to a "public" name server and an "hosts" file to traduce "internal" names are required. The usage of a real "caching" name server is NOT mandatory. The customization of the "SockD" server is easier. The support of UDP associated of V5 is a little bit modified to add support for a "remote" ping command when the destination port is "1". In this case sockd opens a "raw" socket with protocol "icmp" to ping the external host and communicates with the standard UDP Associated protocol to the "client" host. ═══ 2. Auto-dial facility. ═══ You need to customize first the access to your network provider. SockD was only tested with IBM Global Network. When the access is working with the "dialer.exe", you have to customize two "cmd" files one to get the access and the second one to close it. This facility is only supported on one adapter sl0, sl1, ppp0 or ppp1. It was only tested on sl0. To check if the connection is OK, sockd uses the "flags" of the adapter status. When the sl0 adapter is "", the flags are "811" or "" ("851")... Sockd reads normally a sockd.cfg and sockd.rte files in the ETC directory. These files are the socks configuration. In auto-dial mode, sockd tries to build an "automatic" config. It should be OK for the first tests. If you want to look at this default config, you have just to read the sockd.log file (in the sockd directory) after stopping sockd. By sample I used this sockdial.cmd whith a correct userid/password and account to start the connection. /************************************************/ /* */ /* sockdial.cmd : to start the slip connection */ /* */ /************************************************/ 'start dialer account userid password -d' And this sockclos.cmd to stop the connection after the "delay" without session is expired. /***********************************************/ /* */ /* sockclos.cmd : to stop the slip connection */ /* */ /***********************************************/ 'dialer -c' These two cmd MUST be put in a subdirectory in the PATH statement (I used \TCPIP\BIN). Evidendly you have to enable the "auto-dial" function through the "dial-up" option of the "config" menu (and setup your command names and the "delay" time). Then you have to stop/start sockd. An other method consists in starting directly sockd with a parameter: start sockd -dsl0 where: sl0 is the auto-dial adapter In this case you have to keep the default for other parameters: "sockdial.cmd", "sockclos.cmd" and 5 minutes of delay. The delay time should be shorter than the "delay" set in the "dialer" configuration to keep the control of the connection in "sockd". ═══ 3. sockd.cfg ═══ The configuration files are saved in the ETC directory. deny 0.0.0.0 0.0.0.0 9.0.0.0 255.0.0.0 gt 0 permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 ge 1024 permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 21 permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 20 permit *=PhilG,Test 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 23 permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 70 permit 9.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 eq 80 A list of userids can be used in addition of IP addresses on the "permit" statement. They are case sensitive. The value sent from the OS/2 Warp station comes from the USER variable set in the "config.sys" in SOCKS V4. On the time being no checking of "password" is performed (through identd). In SOCKS V5, the userid used in userid/password authentication is checked with the userid list in the permit statement if *= field is set. Good practice specifies a first statement to denies all external accesses to your "private" network (all ports) with: "deny 0.0.0.0 0.0.0.0 nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm gt 0" where nnn is your network number and mmm the mask. then you can permit all stations from your network to access all TCP applications through the socks gateway with: "permit nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm 0.0.0.0 0.0.0.0 gt 0" "proxy" statements can be added if you require to interconnect sockd servers. The syntax is like : "proxy IP_addr port_nb subnet_nb subnet_mask [site_certificate] " Where : IP_addr is the IP address of next proxy server port_nb is the port number (1080 by default) of this proxy server subnet_nb is the destination subnet number we can access through this proxyu subnet_mask the destination subnet mask site_certificate the file to use for authentication and encryption ═══ 4. sockd.pro ═══ SOCKD uses also a profile file (sockd.pro) in the ETC directory to save the number of sessions set, server port nb, the window position, the level of logging used ("Full", "all Sessions", "only errors and sessions refused (Minimum)" or "No logging") and the font used on main window. In the second line of this file, we have the "auto dial" parameters: is this facility enabled (Y or N), the dial command, the hangup command, and the "short hold mode" delay. In addition a "TCP" time-out and a "UDP" time-out (in seconds) are also set. These permit to "tune" the delay sockd is waiting for the next transaction before considering the session is lost. If these parameters are too short sockd is cutting the session during a normal "wait" time. If they are too long, some "client" threads can be blocked and are not available for "new" sessions. The defaults are respectively 20 minutes for TCP and 50 seconds for UDP applications. TCP is really using a "session". In UDP there is no real session. The communication is never really closed. The UDP time-out is used to standardly close this communication. SockD was tested with Real-Audio UDP application and archie as UDP associate applications. The default of 50 seconds was enough to use both applications with a dial-up connection. The default of 20 minutes for TCP applications was set bigger than the standard FTP time-out (15 minutes). It is NOT enough for "permanent" telnet sessions. A third line contains info on log archiving : yes or no, delay in hours or days, delay value, maximum number of files to archive. The fifth parm in this line permits to support only socks V5 userid/password authentication if a userid is set on a permit statement. In Socks V4 there is no password checking. Normally sockd is giving the same process to V4 as V5. Enabling this option obliges to use a password in addition to the userid. This file is created automatically by sockd.exe ═══ 5. sockd.rte ═══ Another configuration file (sockd.rte) is required for SOCKS_BIND in the ETC directory describing the gateway adapters and IP addresses. Most of the applications (Web Explorer, Rtelnet, ...) use only SOCKS_CONNECT. That's the reason why I put "sockd.rte" as optional.... But if you want to use Rftp you need the SOCKS_BIND support and then sockd.rte. It is a list of the local adapter addresses and the neworks you can reach through these... These definitions are used in sequence for testing an address. Thus it seems better to put the more restrictive definitions first (describing private network access) and the "public network" adapter finally (giving access to world). By sample : 9.36.69.41 9.36.69.32 255.255.255.224 9.132.89.238 0.0.0.0 0.0.0.0 If you plan to use the auto-dial facility avoid to set routing for the dial-up adapter. If no route file is found, sockd builds one with your LAN adapters giving access to their local subnets and put a last dynamic entry for the switched adapter giving access to world (0.0.0.0). You can want to have other subnets accessible through fixed (LAN) adapters. For that you must define a sockd.rte with a line per subnet and setting in first parameter the local IP address giving access to it. Sockd 'll add dynamically a last entry for the switched adapter giving access to 0.0.0.0 By sample : 9.36.71.9 9.36.71.0 255.255.255.0 9.132.89.238 9.0.0.0 255.0.0.0 9.132.89.238 198.74.69.0 255.255.255.0 ═══ 6. sockd.usr ═══ This file is in the ETC directory for Socks version 5 userid/password authentication. On the time being, no encryption technic is used on this confidential dataset. A userid as a password can theoretically use 256 characters. I think in our test implementation it is limited to 255 (due to the end of string character). By sample : userid01 password01 userid02 password02 ═══ 7. Utilisation: ═══ Start sockd without any parameter or with some of these options:  "-c" option: The number of concurrent clients is 32 by default. It can be changed at startup with the -c parameter or by modifying the sockd.pro profile file with the menu option. By sample :"sockd -c64" to support 64 simultaneous clients. Note there is NO space between -c and the value. This number should be between 8 and 255. Each client uses one thread (in addition to the base sockd thread).  "-l" option: to suppress logging (sockd.log file in the current directory)  "-i" option: to start iconized .  "-d" option: to setup an auto-dial adapter, by sample "-dsl0".  "-p" option: by default sockd uses the port 1080. You can change it starting "sockd -p2080" by sample. If you want to use more than one option, specify different parameters: "start sockd -c48 -p2080 -i". The frame forwarding MUST be disabled (with the "ipgate off" command or through MPTS customization) to protect the access to your "internal" network. The "socks" support is required to run (and use) applications through gateway. (see SOCKS FORUM) or a Web Browser with "socks" support (like Web Explorer for OS/2). ═══ 8. SOCKD menu ═══  "Config": create, modify or simply check your configuration - "edit": to create or modify "line by line" the sockd.cfg in ETC directory - "proxy": to define proxy servers and the subnets they are giving access. - "view": to review the configuration in memory and eventualy change it with the standard MLE (Multiple Line Entry field) keyboard manipulation. (select text with mouse button 1 or Shift key and move the cursor, then cut, copy and paste text with Ctrl+Delete, Shift+Delete and Shift+Insert) - "profile": to change the maximum number of concurrent sessions, the server port number or the logging level. - "route": to configure the sockd.rte file in ETC directory. - "save conf": to save the sockd.cfg from memory to ETC directory - "userid": for Socks V5 Userid/Password authentication method - "dial-up": to customize auto-dial facility - "font": to select the font used in the main window.  "reset": If you want to activate a change, a new profile or config - "server": to stop/restart the server - "log file": to clean the log file when reports are too long.  "Report": - "accepted": to check all sessions through this server - "denied": to check all demands rejected by the server. - "connect": to read the dial-up connection time in auto-dial mode.  "Help": to read this help file.  "Exit": to save the "profile" file and exit. ═══ 9. DNS support ═══ ═══ 9.1. How to setup a Name server ═══ To solve the V4 "name" problem, I put the DNS kit (at CSD UN60004 level) on the PS/VP. This name server should be customized with caching to the external name server(s) and to internal domain name server. On the "client" station the resolv2 file points to the socks gateway address as the name server (the DNS running on the sockd station can be the only name server on this small subnet). Here after the configuration files used during our tests, where:  Where test.benelux.ibm.com (9.36.71.0) is the 'private' domain  ztmaixn1.benelux.ibm.com (9.132.56.2) is the external name server for the ibm.com domain and ns01.ny.us.ibm.net (165.87.194.244) is the external DNS server.  The socks gateway is using 9.132.89.238 on the "ibm.com" adapter and 9.36.71.9 on the "secure" side (philg.benelux.ibm.com).  Tests were performed from testuser.test.benelux.ibm.com (9.36.71.10).  All "external" sessions were performed through the sl0 adapter and a connection to IBM Global Network as "Service" provider. In fact, on a small LAN with just a few PCs connected a "hosts" file must be enough to succeed with DNS conversion in Socks V5. hosts file in ETC directory 9.132.89.238 bedb238.benelux.ibm.com 9.36.71.9 bedb238.philg.benelux.ibm.com 9.36.71.10 testuser.philg.benelux.ibm.com 165.87.194.244 ns01.ny.us.ibm.net 128.123.35.151 hobbes.nmsu.edu 206.101.97.101 www.lycos.com 205.216.146.70 www.yahoo.com In Socks V4, you can perform the first sockd tests just with a similar hosts file. But quickly, you should be blocked and due to the protocol you need to start a "named" server on your sockd gateway. You need then a "resolv2" file on your LAN attached PC pointing to your named server. In any case keep also an "hosts" file on your sockd PC, because the code uses a "gethostbyaddr()" macro to get the "hostname" of the workstation. Sometimes the named server doesn't answer and you have to start sockd before named. You need then the "hosts" file to get a name. ═══ 9.2. DNS Kit of TCP/IP V2 ═══ named.bt ; ; NAMED.BT file for name server configuration. ; ; type domain source file or host ; domain philg.benelux.ibm.com cache . d:\\tcpip\\etc\\namedb\\named.ca primary philg.benelux.ibm.com d:\\tcpip\\etc\\namedb\\named.dom primary 71.36.9.in-addr.arpa d:\\tcpip\\etc\\namedb\\named.rev ; ; domain benelux.ibm.com primary ztmaixn1.benelux.ibm.com 9.132.56.2 primary 9.in-addr.arpa 9.132.56.2 ; domain ibm.net primary ns01.ny.us.ibm.net 165.87.194.244 primary .in-addr.arpa 165.87.194.244 ; named.ca ; ; define parent(root) domain nameserver (Note trailing dot) ; philg.benelux.ibm.com. 99999999 IN NS bedb238.benelux.ibm.com. 71.36.9.in-addr.arpa. 99999999 IN NS bedb238.benelux.ibm.com. benelux.ibm.com. 99999999 IN NS ztmaixn1.benelux.ibm.com. ibm.com. 99999999 IN NS ztmaixn1.benelux.ibm.com. 9. 99999999 IN NS ztmaixn1.benelux.ibm.com. 9.in-addr.arpa. 99999999 IN NS ztmaixn1.benelux.ibm.com. in-addr.arpa. 99999999 IN NS ns01.ny.us.net.com. ; ; address of domain nameservers ; bedb238.philg.benelux.ibm.com. 99999999 IN A 9.36.71.9 bedb238.benelux.ibm.com. 99999999 IN A 9.132.89.238 ztmaixn1.benelux.ibm.com. 99999999 IN A 9.132.56.2 beda002.benelux.ibm.com. 99999999 IN A 9.132.88.2 ns01.ny.us.net.com. 99999999 IN A 165.87.194.244 ; Where ns01.ny.us.net.com is the name server of the Internet provider... named.dom ; ;******************************** ;* Start of Authority Records * ;******************************** ; @ IN SOA bedb238.philg.benelux.ibm.com. bedb238.philg.benelux.ibm.com. ( 93052601 ; Serial number for this data (yymmdd##) 86400 ; Refresh value for secondary name servers 300 ; Retry value for secondary name servers 864000 ; Expire value for secondary name servers 3600 ) ; Minimum TTL value ; @ IN NS bedb238.philg.benelux.ibm.com. ibm.com. IN NS bedb238.philg.benelux.ibm.com. ibm.com. IN NS ztmaixn1.benelux.ibm.com. com. IN NS bedb238.philg.benelux.ibm.com. com. IN NS ns01.ny.us.ibm.net edu. IN NS ns01.ny.us.ibm.net be. IN NS ns01.ny.us.ibm.net ; ;******************************** ;* Domain Address Information * ;******************************** ; bedb238 86400 IN A 9.36.71.9 IN HINFO IBM-PS/2 OS/2 3.0 ; testuser 86400 IN A 9.36.71.10 IN HINFO IBM-PS/2 OS/2 3.0 ; bedb238.benelux.ibm.com. 86400 IN A 9.132.89.238 bedb237.benelux.ibm.com. 86400 IN A 9.132.89.237 ns01.ny.us.ibm.net 86400 IN A 165.87.194.244 ztmaixn1.benelux.ibm.com 86400 IN A 9.132.56.2 w3.almaden.ibm.com. 86400 IN A 129.33.24.62 w3.pe.au.ibm.com. 86400 IN A 9.8.32.2 w3.austin.ibm.com. 86400 IN A 9.3.246.8 w3.bocaraton.ibm.com. 86400 IN A 9.83.4.179 w3.portsmouth.uk.ibm.com. 86400 IN A 9.180.145.185 w3.hursley.ibm.com. 86400 IN A 9.20.2.34 w3.issc.ibm.com. 86400 IN A 9.242.89.217 isscw3.raleigh.ibm.com. 86400 IN A 9.67.1.114 w3nhd.raleigh.ibm.com. 86400 IN A 9.67.195.102 netstd.raleigh.ibm.com. 86400 IN A 9.67.1.114 w3.raleigh.ibm.com. 86400 IN A 9.67.4.22 www.tcp.raleigh.ibm.com. 86400 IN A 9.67.106.6 www.lycos.com. 86400 IN A 206.101.97.101 www.yahoo.com. 86400 IN A 205.216.146.70 The translation of www.lycos.com, www.yahoo.com, ... Are there to have a method to start a dial-up connection without the external DNS server. These name translations are required for Socks V4 auto-dial process... You must setup there the addresses of the WWW servers set in the quicklist of the end-users connected on the local LAN while Web explorer is not supporting V5. named.rev ; ;******************************** ;* Start of Authority Records * ;******************************** ; 71.36.9.in-addr.arpa. IN SOA bedb238.philg.benelux.ibm.com. ( 93052601 ; Serial number for this data (yymmdd##) 86400 ; Refresh value for secondary name servers 300 ; Retry value for secondary name servers 864000 ; Expire value for secondary name servers 3600 ) ; Minimum TTL value 71.36.9.in-addr.arpa. IN NS bedb238.philg.benelux.ibm.com. ; 9 IN PTR bedb238.philg.benelux.ibm.com. 10 IN PTR testuser.philg.benelux.ibm.com. 237.89.132.9.in-addr.arpa. IN PTR bedb237.benelux.ibm.com. 238.89.132.9.in-addr.arpa. IN PTR bedb238.benelux.ibm.com. 101.97.101.206.in-addr.arpa. IN PTR www.lycos.com. 70.146.216.205.in-addr.arpa. IN PTR www.yahoo.com. The translation of bedb238.benelux.ibm.com is required to start sockd when the name server is running, because 9.132.89.238 is the IP address of the "lan0" adapter. SockD uses a "gethostbyaddr()" macro to get the host-name of the system where it is running. If the name server can not give it, sockd is blocked during start-up... ═══ 9.3. DDNS Kit of Warp server ═══ In the \MPTN\ETC\NAMEDB directory we used the following config files. named.bt ; ; NAMED.BT file for name server configuration. ; ; type domain source file or host ; domain philg.benelux.ibm.com primary philg.benelux.ibm.com c:\\mptn\\etc\\namedb\\named.dom presecured nokeytosec primary 71.36.9.in-addr.arpa c:\\mptn\\etc\\namedb\\named.rev presecured nokeytosec ; ; cache . c:\\mptn\\etc\\namedb\\named.ca presecured nokeytosec ; named.dom ; ;******************************** ;* Start of Authority Records * ;******************************** ; @ IN SOA bedb238.philg.benelux.ibm.com. ( 96090101 ; Serial number for this data (yymmdd##) 86400 ; Refresh value for secondary name servers 300 ; Retry value for secondary name servers 864000 ; Expire value for secondary name servers 3600 ) ; Minimum TTL value ; @ IN NS bedb238.philg.benelux.ibm.com. ; ;******************************** ;* Domain Address Information * ;******************************** ; bedb238 86400 IN A 9.36.71.9 IN HINFO IBM-PS/2 OS/2 3.0 ; testuser 86400 IN A 9.36.71.10 IN HINFO IBM-PS/2 OS/2 3.0 ; ns01.ny.us.ibm.net 86400 IN A 165.87.194.244 www.lycos.com. 86400 IN A 206.101.97.101 www.yahoo.com. 86400 IN A 205.216.146.70 named.rev ; ;******************************** ;* Start of Authority Records * ;******************************** ; 71.36.9.in-addr.arpa. IN SOA bedb238.philg.benelux.ibm.com. ( 93052601 ; Serial number for this data (yymmdd##) 86400 ; Refresh value for secondary name servers 300 ; Retry value for secondary name servers 864000 ; Expire value for secondary name servers 3600 ) ; Minimum TTL value 71.36.9.in-addr.arpa. IN NS bedb238.philg.benelux.ibm.com. ; 9.71.36.9.in-addr.arpa. IN PTR bedb238.philg.benelux.ibm.com. 10.71.36.9.in-addr.arpa. IN PTR testuser.philg.benelux.ibm.com. 101.97.101.206.in-addr.arpa. IN PTR www.lycos.com. 70.146.216.205.in-addr.arpa. IN PTR www.yahoo.com. named.ca ; ; define parent(root) domain nameserver (Note trailing dot) ; in-addr.arpa. 99999999 IN NS ns01.ny.us.net.com. ; ; address of domain nameservers ; ns01.ny.us.net.com. 99999999 IN A 165.87.194.244 ; ═══ 9.4. resolv2 on SockD server ═══ domain philg.benelux.ibm.com nameserver 9.36.71.9 ═══ 9.5. resolv on SockD server ═══ domain philg.benelux.ibm.com nameserver 9.36.71.9 ═══ 9.6. resolv2 on end-user workstation ═══ domain philg.benelux.ibm.com nameserver 9.36.71.9 ═══ 9.7. Test configuration ═══ ---- ---- --- ---- ---- ---- Internet -- ---- - ------ IBM IGN -- ---*------- * * ******* testuser * * Modem ---------- * * Dial-up *Thinkpad* * ----*----- * * * * * * ------*------ Ethernet *9.36.71.10 * T-R *** PS/VP *---------------------*--- * * * bebd238 *9.36.71.9 * * ------------- 9.132.89.238 ibm.com philg.benelux.ibm.com 9.0.0.0 9.36.71.0 With a correct setup, it is possible to use Internal servers (ibm.com) without dialing from "testuser". If an external server is used (by sample www.yahoo.com) the auto-dial is automaticcally used. The choice is done through "sockd.rte" configuration. By default sockd gives only access to the "local" subnet on the LAN adapter (9.132.88.0). ═══ 10. Proxy support ═══ A "proxy" socks server is implemented. To use it you need to know the IP address of the next sockd for OS/2 server and the subnets you can access through this remote sockd. From a LAN connected to Internet in "auto-dial" mode it is possible to access servers located on an other LAN attached to Internet through a sockd using a fixed IP address (mainly with a leased line). You must "permit" the access on both sockd servers. Only the dial-up sockd has to define the "leased line attached" sockd with a "proxy" statement. ═══ 11. Archiving sockd log files and reporting ═══ Sockd can now archive its log files. The setup is done through the "profile" option of the main window menu. Four parameters are saved in the third line of the sockd.pro file in the ETC directory. The first parameter indicates if Yes or No the option is selected. The second parameter is "H" for hours or "D" for days. The third gives the delay used to close the sockd.log file and rename it to "sockdlog.XXX" where XXX is a three digits number. The fourth indicates the maximum number of archived files (+ the current sockd.log). The default is to keep seven files and to archive every 24 hours. With this setup you can build a weekly report using the sample REXX reporting program "sockdrep.cmd" (just type "sockdrep" without parm in the directory sockd is running)... ═══ 12. SOCKS version 4 : A protocol for TCP proxy across firewalls ═══ A protocol for TCP proxy across firewalls SOCKS was originally developed by David Koblas and subsequently modified and extended by Ying-Da Lee from NEC Systems Laboratory to its current running version -- version 4. It is a protocol that relays TCP sessions at a firewall host to allow application users transparent access across the firewall. Because the protocol is independent of application protocols, it can be (and has been) used for many different services, such as telnet, ftp, finger, whois, gopher, WWW,... Access control can be applied at the beginning of each TCP session; thereafter the server simply relays the data between the client and the application server, incurring minimum processing overhead. Since SOCKS never has to know anything about the application protocol, it should also be easy for it to accommodate applications which use encryption to protect their traffic from nosey snoopers. Two operations are defined: CONNECT and BIND. ═══ 12.1. CONNECT ═══ The client connects to the SOCKS server and sends a CONNECT request when it wants to establish a connection to an application server. The client includes in the request packet the IP address and the port number of the destination host, and userid, in the following format. +----+----+----+----+----+----+----+----+----+----+....+----+ | VN | CD | DSTPORT | DSTIP | USERID |NULL| +----+----+----+----+----+----+----+----+----+----+....+----+ # bytes: 1 1 2 4 variable 1 VN is the SOCKS protocol version number and should be 4. CD is the SOCKS command code and should be 1 for CONNECT request. NULL is a byte of all zero bits. The SOCKS server checks to see whether such a request should be granted based on any combination of source IP address, destination IP address, destination port number, the userid, and information it may obtain by consulting IDENT, cf. RFC 1413. If the request is granted, the SOCKS server makes a connection to the specified port of the destination host. A reply packet is sent to the client when this connection is established, or when the request is rejected or the operation fails. +----+----+----+----+----+----+----+----+ | VN | CD | DSTPORT | DSTIP | +----+----+----+----+----+----+----+----+ # bytes: 1 1 2 4 VN is the version of the reply code and should be 0. CD is the result code with one of the following values: 90: request granted 91: request rejected or failed 92: request rejected becasue SOCKS server cannot connect to identd on the client 93: request rejected because the client program and identd report different user-ids The remaining fields are ignored. The SOCKS server closes its connection immediately after notifying the client of a failed or rejected request. For a successful request, the SOCKS server gets ready to relay traffic on both directions. This enables the client to do I/O on its connection as if it were directly connected to the application server. ═══ 12.2. BIND ═══ The client connects to the SOCKS server and sends a BIND request when it wants to prepare for an inbound connection from an application server. This should only happen after a primary connection to the application server has been established with a CONNECT. Typically, this is part of the sequence of actions: 1. bind(): obtain a socket 2. getsockname(): get the IP address and port number of the socket 3. listen(): ready to accept call from the application server 4. use the primary connection to inform the application server of the IP address and the port number that it should connect to. 5. accept(): accept a connection from the application server The purpose of SOCKS BIND operation is to support such a sequence but using a socket on the SOCKS server rather than on the client. The client includes in the request packet the IP address of the application server, the destination port used in the primary connection, and the userid. +----+----+----+----+----+----+----+----+----+----+....+----+ | VN | CD | DSTPORT | DSTIP | USERID |NULL| +----+----+----+----+----+----+----+----+----+----+....+----+ # bytes: 1 1 2 4 variable 1 VN is again 4 for the SOCKS protocol version number. CD must be 2 to indicate BIND request. The SOCKS server uses the client information to decide whether the request is to be granted. The reply it sends back to the client has the same format as the reply for CONNECT request, i.e., +----+----+----+----+----+----+----+----+ | VN | CD | DSTPORT | DSTIP | +----+----+----+----+----+----+----+----+ #bytes: 1 1 2 4 VN is the version of the reply code and should be 0. CD is the result code with one of the following values: 90: request granted 91: request rejected or failed 92: request rejected becasue SOCKS server cannot connect to identd on the client 93: request rejected because the client program and identd report different user-ids. However, for a granted request (CD is 90), the DSTPORT and DSTIP fields are meaningful. In that case, the SOCKS server obtains a socket to wait for an incoming connection and sends the port number and the IP address of that socket to the client in DSTPORT and DSTIP, respectively. If the DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the client should replace it by the IP address of the SOCKS server to which the cleint is connected. (This happens if the SOCKS server is not a multi-homed host.) In the typical scenario, these two numbers are made available to the application client prgram via the result of the subsequent getsockname() call. The application protocol must provide a way for these two pieces of information to be sent from the client to the application server so that it can initiate the connection, which connects it to the SOCKS server rather than directly to the application client as it normally would. The SOCKS server sends a second reply packet to the client when the anticipated connection from the application server is established. The SOCKS server checks the IP address of the originating host against the value of DSTIP specified in the client's BIND request. If a mismatch is found, the CD field in the second reply is set to 91 and the SOCKS server closes both connections. If the two match, CD in the second reply is set to 90 and the SOCKS server gets ready to relay the traffic on its two connections. From then on the client does I/O on its connection to the SOCKS server as if it were directly connected to the application server. For both CONNECT and BIND operations, the server sets a time limit (2 minutes in current CSTC implementation) for the establishment of its connection with the application server. If the connection is still not establiched when the time limit expires, the server closes its connection to the client and gives up. ═══ 13. SOCKS version 5 ═══ ═══ 13.1. RFC 1928 ═══ Network Working Group M. Leech Request for Comments: 1928 Bell-Northern Research Ltd Category: Standards Track M. Ganis International Business Machines Y. Lee NEC Systems Laboratory R. Kuris Unify Corporation D. Koblas Independent Consultant L. Jones Hewlett-Packard Company March 1996 ═══ 13.2. Status of this Memo ═══ This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Acknowledgments This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations The key contributors are: Marcus Leech: Bell-Northern Research, David Koblas: Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt Ganis: International Business Machines. Introduction The use of network firewalls, systems that effectively isolate an organizations internal network structure from an exterior network, such as the INTERNET is becoming increasingly popular. These firewall systems typically act as application-layer gateways between networks, usually offering controlled TELNET, FTP, and SMTP access. With the emergence of more sophisticated application layer protocols designed to facilitate global information discovery, there exists a need to provide a general framework for these protocols to transparently and securely traverse a firewall. There exists, also, a need for strong authentication of such traversal in as fine-grained a manner as is practical. This requirement stems from the realization that client-server relationships emerge between the networks of various organizations, and that such relationships need to be controlled and often strongly authenticated. The protocol described here is designed to provide a frame- work for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall. The protocol is conceptually a "shimlayer" between the application layer and the transport layer and as such does not provide network-layer gateway services such as forwarding of ICMP messages. This new protocol extends the SOCKS Version 4 model to include UDP, and extends the framework to include provisions for generalized strong authentication schemes, and extends the addressing scheme to encompass domain-name and V6 IP addresses. ═══ 13.3. Procedure for TCP-based clients ═══ When a TCP-based client wishes to establish a connection to an object that is reachable only via a firewall (such determination is left up to the implementation), it must open a TCP connection to the appropriate SOCKS port on the SOCKS server system. The SOCKS service is conventionally located on TCP port 1080. If the connection request succeeds, the client enters a negotiation for the authentication method to be used, authenticates with the chosen method, then sends a relay request. The SOCKS server evaluates the request, and either establishes the appropriate connection or denies it. The client connects to the server, and sends a version identifier/method selection message: +----+----------+----------+ |VER | NMETHODS | METHODS | +----+----------+----------+ | 1 | 1 | 1 to 255 | +----+----------+----------+ The VER field is set to X'05' for this version of the protocol.- The NMETHODS field contains the number of method identifier octets that appear in the METHODS field. The server selects from one of the methods given in METHODS, and sends a METHOD selection message: +----+--------+ |VER | METHOD | +----+--------+ | 1 | 1 | +----+--------+ If the selected METHOD is X'FF', none of the methods listed by the client are acceptable, and the client MUST close the connection. The values currently defined for METHOD are: o X'00' NO AUTHENTICATION REQUIRED o X'01' GSSAPI o X'02' USERNAME/PASSWORD o X'03' to X'7F' IANA ASSIGNED o X'80' to X'FE' RESERVED FOR PRIVATE METHODS o X'FF' NO ACCEPTABLE METHODS The client and server then enter a method-specific subnegotiation Descriptions of the method-dependent subnegotiations appear in separate drafts. Developers of new METHOD support for this protocol should contact IANA for a METHOD number. The ASSIGNED NUMBERS document should be referred to for a current list of METHOD numbers and their corresponding protocols. Compliant implementations MUST support GSSAPI and SHOULD support USERNAME/PASSWORD authentication methods. The SOCKS request is formed as follows: +----+-----+-------+------+----------+----------+ |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT | +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00' | 1 | Variable | 2 | +----+-----+-------+------+----------+----------+ Where: o VER protocol version: X'05' o CMD o CONNECT X'01' o BIND X'02' o UDP ASSOCIATE X'03' o RSV RESERVED o ATYP address type of following address o IP V4 address: X'01' o DOMAINNAME: X'03' o IP V6 address: X'04' o DST.ADDR desired destination address o DST.PORT desired destination port in network octet order The SOCKS server will typically evaluate the request based on source and destination addresses, and return one or more reply messages, as appropriate for the request type. ═══ 13.4. Addressing ═══ In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies the type of address contained within the field:  X'01' the address is a version-4 IP address, with a length of 4 octets  X'03' the address field contains a DNS-style domain name. The first octet of the address field contains the number of octets that follow.  X'04' the address is a version-6 IP address, with a length of 16 octets. Address resolution proxy: Because of the protocol limitation, Version 4 based SOCKS servers require full DNS support to be operational (every SOCKS V4 client must be able to resolve all the accessible destination addresses). The built-in address resolution proxy in Version 5 based SOCKS server will enables SOCKS V5 clients to be fully operational without having DNS support. A SOCKS client can pass the name, instead of resolved address, to the SOCKS server and the server will resolve the address for the client. ═══ 13.5. Replies ═══ The SOCKS request information is sent by the client as soon as it has established a connection to the SOCKS server, and completed the authentication negotiations. The server evaluates the request, and returns a reply formed as follows: +----+-----+-------+------+----------+----------+ |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT | +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00' | 1 | Variable | 2 | +----+-----+-------+------+----------+----------+ Where: o VER protocol version: X'05' o REP Reply field: o X'00' succeeded o X'01' general SOCKS server failure o X'02' connection not allowed by ruleset o X'03' Network unreachable o X'04' Host unreachable o X'05' Connection refused o X'06' TTL expired o X'07' Command not supported o X'08' Address type not supported o X'09' to X'FF' unassigned o RSV RESERVED o ATYP address type of following address o IP V4 address: X'01' o DOMAINNAME: X'03' o IP V6 address: X'04' o BND.ADDR server bound address o BND.PORT server bound port in network octet order Fields marked RESERVED (RSV) must be set to X'00'. If the chosen method includes encapsulation for purposes of authentication, integrity and/or confidentiality, the replies are encapsulated in the method-dependent encapsulation. CONNECT In the reply to a CONNECT, BND.PORT contains the port number that the server assigned to connect to the target host, while BND.ADDR contains the associated IP address. The supplied BND.ADDR is often different from the IP address that the client uses to reach the SOCKS server, since such servers are often multi-homed. It is expected that the SOCKS server will use DST.ADDR and DST.PORT, and the client- side source address and port in evaluating the CONNECT request. BIND The BIND request is used in protocols which require the client to accept connections from the server. FTP is a well-known example, which uses the primary client-to-server connection for commands and status reports, but may use a server-to-client connection for transferring data on demand (e.g. LS, GET, PUT). It is expected that the client side of an application protocol will use the BIND request only to establish secondary connections after a primary connection is established using CONNECT. In is expected that a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND request. Two replies are sent from the SOCKS server to the client during a BIND operation. The first is sent after the server creates and binds a new socket. The BND.PORT field contains the port number that the SOCKS server assigned to listen for an incoming connection. The BND.ADDR field contains the associated IP address. The client will typically use these pieces of information to notify (via the primary or control connection) the application server of the rendezvous address. The second reply occurs only after the anticipated incoming connection succeeds or fails. In the second reply, the BND.PORT and BND.ADDR fields contain the address and port number of the connecting host. UDP ASSOCIATE The UDP ASSOCIATE request is used to establish an association within the UDP relay process to handle UDP datagrams. The DST.ADDR and DST.PORT fields contain the address and port that the client expects to use to send UDP datagrams on for the association. The server MAY use this information to limit access to the association. If the client is not in possesion of the information at the time of the UDP ASSOCIATE, the client MUST use a port number and address of all zeros. A UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates. In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR fields indicate the port number/address where the client MUST send UDP request messages to be relayed. Reply Processing When a reply (REP value other than X'00') indicates a failure, the SOCKS server MUST terminate the TCP connection shortly after sending the reply. This must be no more than 10 seconds after detecting the condition that caused a failure. If the reply code (REP value of X'00') indicates a success, and the request was either a BIND or a CONNECT, the client may now start passing data. If the selected authentication method supports encapsulation for the purposes of integrity, authentication and/or confidentiality, the data are encapsulated using the method-dependent encapsulation. Similarly, when data arrives at the SOCKS server for the client, the server MUST encapsulate the data as appropriate for the authentication method in use. Procedure for UDP-based clients A UDP-based client MUST send its datagrams to the UDP relay server at the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE request. If the selected authentication method provides encapsulation for the purposes of authenticity, integrity, and/or confidentiality, the datagram MUST be encapsulated using the appropriate encapsulation. Each UDP datagram carries a UDP request header with it: +----+------+------+----------+----------+----------+ |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | +----+------+------+----------+----------+----------+ | 2 | 1 | 1 | Variable | 2 | Variable | +----+------+------+----------+----------+----------+ The fields in the UDP request header are: o RSV Reserved X'0000' o FRAG Current fragment number o ATYP address type of following addresses: o IP V4 address: X'01' o DOMAINNAME: X'03' o IP V6 address: X'04' o DST.ADDR desired destination address o DST.PORT desired destination port o DATA user data When a UDP relay server decides to relay a UDP datagram, it does so silently, without any notification to the requesting client. Similarly, it will drop datagrams it cannot or will not relay. When a UDP relay server receives a reply datagram from a remote host, it MUST encapsulate that datagram using the above UDP request header, and any authentication- method-dependent encapsulation. The UDP relay server MUST acquire from the SOCKS server the expected IP address of the client that will send datagrams to the BND.PORT given in the reply to UDP ASSOCIATE. It MUST drop any datagrams arriving from any source IP address other than the one recorded for the particular association. The FRAG field indicates whether or not this datagram is one of a number of fragments. If implemented, the high-order bit indicates end-of-fragment sequence, while a value of X'00' indicates that this datagram is standalone. Values between 1 and 127 indicate the fragment position within a fragment sequence. Each receiver will have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these fragments. The reassembly queue must be reinitialized and the associated fragments abandoned whenever the REASSEMBLY TIMER expires, or a new datagram arrives carrying a FRAG field whose value is less than the highest FRAG value processed for this fragment sequence. The reassembly timer MUST be no less than 5 seconds. It is recommended that fragmentation be avoided by applications wherever possible. Implementation of fragmentation is optional; an implementation that does not support fragmentation MUST drop any datagram whose FRAG field is other than X'00'. The programming interface for a SOCKS-aware UDP MUST report an available buffer space for UDP datagrams that is smaller than the actual space provided by the operating system: o if ATYP is X'01' - 10+method_dependent octets smaller o if ATYP is X'03' - 262+method_dependent octets smaller o if ATYP is X'04' - 20+method_dependent octets smaller ═══ 13.6. Security Considerations ═══ This document describes a protocol for the application-layer traversal of IP network firewalls. The security of such traversal is highly dependent on the particular authentication and encapsulation methods provided in a particular implementation, and selected during negotiation between SOCKS client and SOCKS server. Careful consideration should be given by the administrator to the selection of authentication methods. Authors Address Marcus Leech Bell-Northern Research P.O. Box 3511, Stn. C, Ottawa, ON CANADA K1Y 4H7 Email: mleech@bnr.ca ═══ 13.7. Username/Password Authentication for SOCKS V5 ═══ Username/Password Authentication for SOCKS V5 Network Working Group M. Leech Request for Comments: 1929 Bell-Northern Research Ltd Category: Standards Track March 1996 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Introduction The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". Note: Unless otherwise noted, the decimal numbers appearing in packet- format diagrams represent the length of the corresponding field, in octets. Where a given octet must take on a specific value, the syntax X'hh' is used to denote the value of the single octet in that field. When the word 'Variable' is used, it indicates that the corresponding field has a variable length defined either by an associated (one or two octet) length field, or by a data type field. Initial negotiation Once the SOCKS V5 server has started, and the client has selected the Username/Password Authentication protocol, the Username/Password subnegotiation begins. This begins with the client producing a Username/Password request: +----+------+----------+------+----------+ |VER | ULEN | UNAME | PLEN | PASSWD | +----+------+----------+------+----------+ | 1 | 1 | 1 to 255 | 1 | 1 to 255 | +----+------+----------+------+----------+ The VER field contains the current version of the subnegotiation, which is X'01'. The ULEN field contains the length of the UNAME field that follows. The UNAME field contains the username as known to the source operating system. The PLEN field contains the length of the PASSWD field that follows. The PASSWD field contains the pass- word association with the given UNAME. The server verifies the supplied UNAME and PASSWD, and sends the following response: +----+--------+ |VER | STATUS | +----+--------+ | 1 | 1 | +----+--------+ A STATUS field of X'00' indicates success. If the server returns a `failure' (STATUS value other than X'00') status, it MUST close the connection. Security Considerations This document describes a subnegotiation that provides authentication services to the SOCKS protocol. Since the request carries the password in cleartext, this subnegotiation is not recommended for environments where "sniffing" is possible and practical. Authors Address Marcus Leech Bell-Northern Research Ltd P.O. Box 3511, Station C Ottawa, ON CANADA K1Y 4H7 +1 613 763 9145 Email: mleech@bnr.ca ═══ 14. RFC1918 : Address Allocation for Private Internets ═══ Network Working Group Y. Rekhter Request for Comments: 1918 Cisco Systems Obsoletes: 1627, 1597 B. Moskowitz BCP: 5 Chrysler Corp. Category: Best Current Practice D. Karrenberg RIPE NCC G. J. de Groot RIPE NCC E. Lear Silicon Graphics, Inc. February 1996 ═══ 14.1. Status of this Memo ═══ This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. ═══ 14.2. Introduction ═══ For the purposes of this document, an enterprise is an entity autonomously operating a network using TCP/IP and in particular determining the addressing plan and address assignments within that network. This document describes address allocation for private internets. The allocation permits full network layer connectivity among all hosts inside an enterprise as well as among all public hosts of different enterprises. The cost of using private internet address space is the potentially costly effort to renumber hosts and networks between public and private. ═══ 14.3. Motivation ═══ With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. The Internet has grown beyond anyone's expectations. Sustained exponential growth continues to introduce new challenges. One challenge is a concern within the community that globally unique address space will be exhausted. A separate and far more pressing concern is that the amount of routing overhead will grow beyond the capabilities of Internet Service Providers. Efforts are in progress within the community to find long term solutions to both of these problems. Meanwhile it is necessary to revisit address allocation procedures, and their impact on the Internet routing system. To contain growth of routing overhead, an Internet Provider obtains a block of address space from an address registry, and then assigns to its customers addresses from within that block based on each customer requirement. The result of this process is that routes to many customers will be aggregated together, and will appear to other providers as a single route ╒RFC1518■, ╒RFC1519■. In order for route aggregation to be effective, Internet providers encourage customers joining their network to use the provider's block, and thus renumber their computers. Such encouragement may become a requirement in the future. With the current size of the Internet and its growth rate it is no longer realistic to assume that by virtue of acquiring globally unique IP addresses out of an Internet registry an organization that acquires such addresses would have Internet-wide IP connectivity once the organization gets connected to the Internet. To the contrary, it is quite likely that when the organization would connect to the Internet to achieve Internet-wide IP connectivity the organization would need to change IP addresses (renumber) all of its public hosts (hosts that require Internet-wide IP connectivity), regardless of whether the addresses used by the organization initially were globally unique or not. It has been typical to assign globally unique addresses to all hosts that use TCP/IP. In order to extend the life of the IPv4 address space, address registries are requiring more justification than ever before, making it harder for organizations to acquire additional address space ╒RFC1466■. Hosts within enterprises that use IP can be partitioned into three categories:  Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises.  Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises.  Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous. We will refer to the hosts in the first and second categories as "private". We will refer to the hosts in the third category as "public". Many applications require connectivity only within one enterprise and do not need external (outside the enterprise) connectivity for the majority of internal hosts. In larger enterprises it is often easy to identify a substantial number of hosts using TCP/IP that do not need network layer connectivity outside the enterprise. Some examples, where external connectivity might not be required, are:  A large airport which has its arrival/departure displays individually addressable via TCP/IP. It is very unlikely that these displays need to be directly accessible from other networks.  Large organizations like banks and retail chains are switching to TCP/IP for their internal communication. Large numbers of local workstations like cash registers, money machines, and equipment at clerical positions rarely need to have such connectivity.  For security reasons, many enterprises use application layer gateways to connect their internal network to the Internet. The internal network usually does not have direct access to the Internet, thus only one or more gateways are visible from the Internet. In this case, the internal network can use non-unique IP network numbers.  Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise. ═══ 14.4. Private Address Space ═══ The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) We will refer to the first block as "24-bit block", the second as "20-bit block", and to the third as "16-bit" block. Note that (in pre-CIDR notation) the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and third block is a set of 256 contiguous class C network numbers. An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space so they may communicate with each other in their own private internet. As before, any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry. An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. Moving a host from private to public or vice versa involves a change of IP address, changes to the appropriate DNS entries, and changes to configuration files on other hosts that reference the host by IP address. Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. ═══ 14.5. Advantages and Disadvantages of Using Private Address Space ═══ The obvious advantage of using private address space for the Internet at large is to conserve the globally unique address space by not using it where global uniqueness is not required. Enterprises themselves also enjoy a number of benefits from their usage of private address space: They gain a lot of flexibility in network design by having more address space at their disposal than they could obtain from the globally unique pool. This enables operationally and administratively convenient addressing schemes as well as easier growth paths. For a variety of reasons the Internet has already encountered situations where an enterprise that has not been connected to the Internet had used IP address space for its hosts without getting this space assigned from the IANA. In some cases this address space had been already assigned to other enterprises. If such an enterprise would later connects to the Internet, this could potentially create very serious problems, as IP routing cannot provide correct operations in presence of ambiguous addressing. Although in principle Internet Service Providers should guard against such mistakes through the use of route filters, this does not always happen in practice. Using private address space provides a safe choice for such enterprises, avoiding clashes once outside connectivity is needed. A major drawback to the use of private address space is that it may actually reduce an enterprise's flexibility to access the Internet. Once one commits to using a private address, one is committing to renumber part or all of an enterprise, should one decide to provide IP connectivity between that part (or all of the enterprise) and the Internet. Usually the cost of renumbering can be measured by counting the number of hosts that have to transition from private to public. As was discussed earlier, however, even if a network uses globally unique addresses, it may still have to renumber in order to acquire Internet-wide IP connectivity. Another drawback to the use of private address space is that it may require renumbering when merging several private internets into a single private internet. If we review the examples we list in Section 2, we note that companies tend to merge. If such companies prior to the merge maintained their uncoordinated internets using private address space, then if after the merge these private internets would be combined into a single private internet, some addresses within the combined private internet may not be unique. As a result, hosts with these addresses would need to be renumbered. The cost of renumbering may well be mitigated by development and deployment of tools that facilitate renumbering (e.g. Dynamic Host Configuration Protocol (DHCP)). When deciding whether to use private addresses, we recommend to inquire computer and software vendors about availability of such tools. A separate IETF effort (PIER Working Group) is pursuing full documentation of the requirements and procedures for renumbering. ═══ 14.6. Operational Considerations ═══ One possible strategy is to design the private part of the network first and use private address space for all internal links. Then plan public subnets at the locations needed and design the external connectivity. This design does not need to be fixed permanently. If a group of one or more hosts requires to change their status (from private to public or vice versa) later, this can be accomplished by renumbering only the hosts involved, and changing physical connectivity, if needed. In locations where such changes can be foreseen (machine rooms, etc.), it is advisable to configure separate physical media for public and private subnets to facilitate such changes. In order to avoid major network disruptions, it is advisable to group hosts with similar connectivity needs on their own subnets. If a suitable subnetting scheme can be designed and is supported by the equipment concerned, it is advisable to use the 24-bit block (class A network) of private address space and make an addressing plan with a good growth path. If subnetting is a problem, the 16-bit block (class C networks), or the 20-bit block (class B networks) of private address space can be used. One might be tempted to have both public and private addresses on the same physical medium. While this is possible, there are pitfalls to such a design (note that the pitfalls have nothing to do with the use of private addresses, but are due to the presence of multiple IP subnets on a common Data Link subnetwork). We advise caution when proceeding in this area. It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. It is possible for two sites, who both coordinate their private address space, to communicate with each other over a public network. To do so they must use some method of encapsulation at their borders to a public network, thus keeping their private addresses private. If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose randomly from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. If an enterprise uses the private address space, or a mix of private and public address spaces, then DNS clients outside of the enterprise should not see addresses in the private address space used by the enterprise, since these addresses would be ambiguous. One way to ensure this is to run two authority servers for each DNS zone containing both publically and privately addressed hosts. One server would be visible from the public address space and would contain only the subset of the enterprise's addresses which were reachable using public addresses. The other server would be reachable only from the private network and would contain the full set of data, including the private addresses and whatever public addresses are reachable the private network. In order to ensure consistency, both servers should be configured from the same data of which the publically visible zone only contains a filtered version. There is certain degree of additional complexity associated with providing these capabilities. ═══ 14.7. Security Considerations ═══ Security issues are not addressed in this memo. ═══ 14.8. Conclusion ═══ With the described scheme many large enterprises will need only a relatively small block of addresses from the globally unique IP address space. The Internet at large benefits through conservation of globally unique address space which will effectively lengthen the lifetime of the IP address space. The enterprises benefit from the increased flexibility provided by a relatively large private address space. However, use of private addressing requires that an organization renumber part or all of its enterprise network, as its connectivity requirements change over time. ═══ 14.9. Acknowledgments ═══ We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans- Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet Software Consortium) for their review and constructive comments. ═══ 15. If problems ═══  The DNS kit nameD server can block if the system is fully "socksified". Don't hesitate to rename the "socks.cfg" file in the ETC directory when you are running sockD.  If your configuration is limited to one LAN adapter and one dial adapter, it is better to test sockd without configuring it... Use the view menu option to see the config. After tests, check sockd.log ...  If you have really a problem to setup a name server on the gateway station, define a "hosts" file. For that, when you are testing your "sockdial.cmd" after the connection and authentication are successfully completed, use : host www.yahoo.com in an OS/2 Window. You are able to get the IP addresses of your favorite servers. If you install a "completed" hosts file in the ETC directory of the end-user PC you can test sockd with WebEx (socks V4) without setting a name server. With a name server and its caching mechanism, you have access to any server, with the hosts file access is limited...  To support socks V5 DNS, the dial-up connection is started automatically if the name can NOT be locally traduced... A better solution is perhaps to define a list of the "internal" domain names, and to start the connection only if the request is for another domain name. On the time being, sockd start the dial-up connection for V5, before checking if the connection is "permitted" except if the DNS name can be locally traduced. With the current implementation: - in socks V4 the first session (to start the dial-up connection) MUST be to a "locally" defined DNS name (then sockd check if the client has access to this address before starting the connection). - in V5 DNS support, the first session can be to any DNS name, but if this name can NOT be locally translatted, there a delay (nearly 1 min. in my tests) then the dial-up connection is started and the DNS name translation request is sent to the "external" name server. The "permission" can be checked only after sockd received the destination IP address.  In this version , only the flags "811" () or "851" (<..,RUNNING>) are considered as "good" status (connection established) on the dial-up adapter. If the "auto-dial" facility doesn't work for you, please check these flags with: "ifconfig ppp0" (by sample) Send a note to me and I'll add the required support...  With current V4 applications like WebEx, the first session must be done to a DNS name converted locally (named or hosts file). After the dial-up connection is established, names can be translatted by the Internet provider name server, and cached in the local nameD.  Using WebEx through sockd, some ".gif" files are not correctly received I am investigating why and how to improve it. Any suggestion or question to Philippe Gillain (GILLAIN at BRUVMIS1 or Philippe_Gillain@be.ibm.com)...